Enhanced registration messages in internet protocol multimedia subsystems

ABSTRACT

An enhanced Session Initiation Protocol (“SIP”) registration message having extended header information that is used by an Internet Protocol Multimedia Subsystem (“IMS”) core to determine the registration status of a mobile device and the physical location of the mobile device. The extended header information includes hardware and subscriber identifiers, such as an International Mobile Equipment Identity (“IMEI”) and International Mobile Subscriber Identity (“IMSI”). The IMS core queries an equipment identity register to validate IMEI/IMSI identifiers in the header to determine whether to deny registration to a mobile device. The IMS core also queries a capability database using an IMEI to determine which location determination techniques are supported by or suitable for the associated mobile device.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 12/856,519, filed on Aug. 13, 2010, and entitled“ENHANCED REGISTRATION MESSAGES IN INTERNET PROTOCOL MULTIMEDIASUBSYSTEMS,” now U.S. Pat. No. 8,537,797, which is hereby incorporatedherein in its entirety by reference.

BACKGROUND

Internet Protocol Multimedia Subsystems (“IMS”) is an architectureframework for delivering Internet Protocol (“IP”) multimedia to mobileusers, such as users of mobile devices. An IMS core network (“IMS core”)permits wireless and wireline devices to access multimedia, messaging,and voice applications and services. IMS standards and specificationshave been promulgated by the 3rd Generation Partnership Project(“3GPP”™) To ease the integration of an IMS core with Internetresources, 3GPP specifications use Internet Engineering Task Forceprotocols within the IMS core, such as Session Initiation Protocol(“SIP”) and Diameter.

SIP is a signaling protocol used for creating, modifying and terminatingtwo-party or multiparty sessions consisting of one or several mediastreams. A mobile device registers its IP address with a SIP registrarserver within an IMS core by generating and sending a SIP requestmessage with a “REGISTER” method token. Once registered, a mobile devicemay subsequently establish multimedia sessions via the IMS core.Standard IMS registration techniques may not permit an IMS core toascertain the IMEI of a mobile device seeking registration. Furthermore,standard IMS registration techniques may not permit an IMS core toascertain the hardware and software capabilities of a particular mobiledevice so that the IMS core may intelligently provision services to themobile device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a representative environment in which enhancedregistration messages may be utilized.

FIG. 2 illustrates an example of an enhanced SIP registration messagehaving extended header information.

FIG. 3 shows a table schema that conceptually illustrates how acapability database stores location determination capabilities of amobile device in association with an IMEI that identifies the mobiledevice.

FIG. 4 is a logical flow diagram of a process for utilizing a SIPregistration message having extended header information in order todetermine the registration status of a mobile device and determine thelocation of the mobile device.

DETAILED DESCRIPTION

An enhanced Session Initiation Protocol (“SIP”) registration messagehaving extended header information that is used by an Internet ProtocolMultimedia Subsystem (“IMS”) core to determine the registration statusof a mobile device and the physical location of the mobile device isdisclosed. The extended header information includes hardware andsubscriber identifiers, such as an International Mobile EquipmentIdentity (“IMEI”) and International Mobile Subscriber Identity (“IMSI”).The IMS core queries an equipment identity register to validateIMEI/IMSI identifiers in the header to determine whether to denyregistration to a mobile device. The IMS core also queries a capabilitydatabase using an IMEI to determine which location determinationtechniques are supported by or suitable for the associated mobiledevice.

Various embodiments of the invention will now be described. Thefollowing description provides specific details for a thoroughunderstanding and an enabling description of these embodiments. Oneskilled in the art will understand, however, that the invention may bepracticed without many of these details. Additionally, some well-knownstructures or functions may not be shown or described in detail, so asto avoid unnecessarily obscuring the relevant description of the variousembodiments. The terminology used in the description presented below isintended to be interpreted in its broadest reasonable manner, eventhough it is being used in conjunction with a detailed description ofcertain specific embodiments of the invention.

A. Representative Environment

FIG. 1 is a diagram of a representative environment 100 in whichenhanced registration messages may be utilized. In the environment 100,mobile devices 102 are configured to communicate with, or through, atrusted radio access network (“RAN”) 104 and/or an untrusted RAN 103, inorder to register with and utilize an IMS core 107.

Users may employ mobile devices 102 to communicate with other users anddevices. In addition, users may employ mobile devices 102 to receive,provide, or otherwise interact with location-based services.Location-based services are services that use the actual or approximatelocation of a mobile device to provide, enhance, or supplement a serviceto the mobile device. Location-based services include, but are notlimited to, services such as emergency services (e.g., E911), assettracking or recovery services (e.g., the tracking of a stolen car),location-based alerts or advertising services (e.g., targetedadvertisements that depend on the location of a mobile device user),social networking services (e.g., services that report the relativelocation of friends or family), and/or the like. Once a mobile device102 has successfully registered with the IMS core 107, the device mayestablish multimedia sessions managed by the IMS core in order to accessapplications and services that facilitate communication, location-basedservices and/or other services.

Mobile devices 102 may include virtually any devices for communicatingover a wireless network. Such devices include mobile telephones, such asGlobal System for Mobile Communications (“GSM”) telephones, TimeDivision Multiple Access (“TDMA”) telephones, Universal MobileTelecommunications System (“UMTS”) telephones, Evolution-Data Optimized(“EVDO”) telephones, Long Term Evolution (“LTE”) telephones, GenericAccess Network (“GAN”) telephones, Unlicensed Mobile Access (“UMA”)telephones, and other mobile computers or devices, such as Voice overInternet Protocol (“VoIP”) devices, Secure User Plane Location (“SUPL”)Enabled Terminals (SETs), Personal Digital Assistants (“PDAs”), radiofrequency devices, infrared devices, handheld computers, laptopcomputers, wearable computers, tablet computers, pagers, integrateddevices combining one or more of the preceding devices, and/or the like.

Given such variety, mobile devices 102 may range widely in terms offeatures and capabilities. As one example, mobile devices may havewidely different hardware and software configurations that affect whichlocation determination techniques may be utilized to locate the physicallocation of a mobile device (e.g., its latitude and longitude). Asanother example, the configuration of a mobile device may affect theperformance (e.g., accuracy, precision, time to fix) of a locationdetermination technique used to physically locate the device. Theconfiguration of a mobile device may also affect its capability toutilize other types of applications or services besides location-basedservices. For example, the configuration of a mobile device may affectits capability to use multimedia gaming applications, instant messagingapplications, etc.

Mobile devices 102 typically include a processing unit, volatile memoryand/or nonvolatile memory, a power supply, one or more networkinterfaces, an audio interface, a display, a keypad or keyboard andother input and/or output interfaces. The various components of a mobiledevice may be interconnected via a bus. The volatile and nonvolatilememories generally include storage media for storing information such asprocessor-readable instructions, data structures, program modules, orother data. Some examples of information that may be stored includebasic input/output systems (BIOS), operating systems, and applications.The stored information may include one or more SIP clients capable ofgenerating, transmitting and interpreting syntactically correct SIPmessages. SIP clients permit the mobile device to register with andcommunicate via the ISM core 107.

Many mobile devices 102 are associated with an International MobileEquipment Identity or IMEI Software Version (herein both are referred toas “IMEI”). An IMEI is a unique or semi-unique hardware identifier thatincludes information on the origin, model, and serial number of a mobiledevice. Some mobile devices that try to register with the IMS core 107may not have an IMEI. For example, a laptop that only connects to theIMS core via a VOIP software client may not have an IMEI. In someexamples, the IMS core may generate a pseudo-IMEI for a mobile devicebased upon an International Mobile Subscriber Identity and/or GloballyRoutable User Agent URI (“GRUU”) associated with the mobile device. Forexample, an S-CSCF (described herein) within the IMS core may generate apseudo-IMEI for a VOIP soft client, an iPAD®, or laptop computer. Such apseudo-IMEI may then be utilized in the methods described herein. Somemobile devices may have one or more unique or semi-unique mobile devicehardware identifiers that are comparable to an IMEI, such as a MobileEquipment Identifier (“MEID”) or Electronic Serial Number (“ESN”).Although the term “IMEI” is used subsequently herein, one having skillin the art will appreciate that the disclosed methods may alternativelyor additionally use other comparable mobile device hardware identifiersto determine the capabilities of a mobile device accessing the IMS core.

A mobile device 102 may also be associated with an International MobileSubscriber Identity (“IMSI”), which is an internationally unique numberused to identify a mobile subscriber or user. A subscriber's IMSI may bestored in a removable user identity card installed in a mobile device102, such as a subscriber identity module (“SIM”) card, Removable UserIdentity Module (“R-UIM”) card, CDMA Subscriber Identify Module (“CSIM”)card, or a Universal Integrated Circuit Card (“UICC”). The removablenature of the user identity card allows a user to change mobile devicesby simply removing the card from one mobile device and inserting thecard into another. Thus, the association between a mobile device and anIMSI may change over time. Furthermore, a mobile device may either bepermanently or temporarily without a user identity card and thereforenot associated with an IMSI.

Mobile devices 102 may connect to the IMS core 107 by a trusted RAN 104or an untrusted RAN 103. Both types of RANs provide a first physicalwireless link between mobile devices 102 and the IMS core. A singlemobile device may be capable of using one or both types of RANs. TheRANs 103, 104 may use any wireless communications and data protocol orstandard, such as GSM, TDMA, UMTS, EVDO, LTE, GAN, UMA, Code DivisionMultiple Access (“CDMA”) protocols (including IS-95, IS-2000, and IS-856protocols), Advanced LTE or LTE+, Orthogonal Frequency Division MultipleAccess (“OFDM”), General Packet Radio Service (“GPRS”), Enhanced DataGSM Environment (“EDGE”), Advanced Mobile Phone System (“AMPS”), WiMAXprotocols (including IEEE 802.16e-2005 and IEEE 802.16m protocols),Wireless Fidelity (“WiFi”), High Speed Packet Access (“HSPA”),(including High Speed Downlink Packet Access (“HSDPA”) and High SpeedUplink Packet Access (“HSUPA”)), Ultra Mobile Broadband (“UMB”), SUPL,and/or the like.

The trusted RAN 104 is a RAN operated by the operator of the IMS core107 or another trusted party that is associated with the IMS coreoperator (e.g., the operator's contractor, affiliate, or industrypartner). In order to wirelessly communicate via the trusted RAN, amobile device 102 may need to pass preliminaryauthentication/authorization checks implemented in part by the trustedRAN. The trusted RAN is connected to and communicates with the IMS corevia a dedicated backhaul (e.g., a private network that is not open tothe public) and intermediary components 106. The intermediary componentsmay include, for example, a Gateway GPRS Support Node (“GGSN”), ServingGPRS Support Node (“SGSN”) or similar components that facilitatemobility management, session management, and transport for IP packetservices within the trusted RAN 104.

The untrusted RAN 103 is a RAN that connects to the IMS core 107 over apublic network such as the Internet. The untrusted RAN may not implementauthentication/authorization tests sufficient to prevent securityattacks upon the IMS core. In some examples, a mobile device 102 uses aWiFi, GAN, or UMA protocol to connect to an untrusted RAN at a wirelessaccess point.

The intermediary components 106 and the untrusted RAN 103 are bothconnected to the IMS core 107. The IMS core comprises various CallSession Control Functions (“CSCF”) and other components that, interalia, provide SIP registrar and proxy functionality. The IMS corecomprises a proxy CSCF (“P-CSCF”) 108, an interrogating CSCF (“I-CSCF”)112, a serving CSCF (“S-CSCF”) 116, a Security Gateway (“SEG”)/SessionBorder Controller (“SBC”) 110, and a Home Subscriber Server (“HSS”) 114.The basic functionalities of the IMS core components are described bystandards promulgated by the 3GPP, including 3GPP TS 23.002, version9.2.0 Release 9, which is hereby incorporated by reference herein in itsentirety.

As shown in FIG. 1, the intermediary components 106 connect the trustedRAN 104 to the IMS core 107 via the P-CSCF 108. In contrast, theuntrusted network 103 connects to the P-CSCF 108 indirectly via theSEG/SBC 110. The SEG/SBC may establish a secure IP tunnel between amobile device 102 and the IMS core. In some examples, a trusted network104 may connect to the P-CSCF via the SEG/SBC. In other examples, theuntrusted network may directly connect to the P-CSCF via the Internet.

In order to register with the IMS core 107, a SIP client running on amobile device 102 generates and sends an initial SIP registrationmessage to the IMS core via the trusted RAN 104 or untrusted RAN 103.The initial registration message comprises a REGISTER method token andextended header information, including an IMEI and IMSI associated withthe mobile device 102, as described in greater detail herein. The P-CSCF108 receives the initial SIP registration message and forwards themessage to the I-CSCF 112. One having skill in the art will appreciatethat in some examples, the P-CSCF may also perform some or all of thefunctionality of the SEG/SBC 110.

The I-CSCF 112 and/or S-CSCF 116 may utilize the IMEI/IMSI identifiersin the received registration message to generate and send a userauthorization request (“UAR”) to the HSS 114 via the Diameter protocol.The UAR includes, inter alia, the IMEI and IMSI associated with themobile device 102. In some examples, the I-CSCF utilizes the SIPregistration message forwarded from the P-CSCF to generate and send theUAR to the HSS and the S-CSCF implements additional standard IMSregistration methods. In other examples, the I-CSCF does not generateand send the UAR, but instead queries the HSS to identify which S-CSCFto forward the registration message to. In such examples, the I-CSCFthen forwards the received SIP registration message to the identifiedS-CSCF. As described in greater detail herein, the S-CSCF then utilizesthe SIP registration message to generate and send the UAR to the HSS.The S-CSCF also implements additional standard IMS registration methods(e.g., HTTP digest or Authentication and Key Agreement (“AKA”)authentication).

The HSS 114 is a master user database that contains subscription-relatedinformation such as subscriber profiles. The HSS performs authenticationand authorization of a mobile device 102 and provides information abouta mobile device's IP address. The HSS may perform standard IMSregistration processes as described by 3GPP specifications andstandards. The HSS also validates the IMEI/IMSI identifiers in the UARin order to determine whether to deny registration to a mobile device102. The HSS may also use a received IMEI to determine the capabilitiesof a mobile device. To authorize a device and determine devicecapabilities, the HSS is configured to use a received UAR in order toquery an equipment identity register (“EIR”) 120.

In some examples, the S-CSCF 116 couples to the EIR 120 directly. Insuch examples, the S-CSCF may validate IMEI/IMSI identifiers in order todetermine whether to deny registration to a mobile device 102. In suchexamples, the S-CSCF may also use a received IMEI to determine thecapabilities of a mobile device. To authorize a device and/or determinedevice capabilities, the S-CSCF may be configured to extract IMEI/IMSIinformation from a SIP registration message and to query the EIR usingthe extracted information.

The EIR 120 is a database used to identify which mobile devices 102 arepermitted to the use IMS core 107. The EIR may also be utilized toidentify which mobile devices are permitted to use the trusted network104. Among other information, the EIR maintains a list of mobile devices(identified by their IMEI) which are to be banned from the network ormonitored, for example because the devices have been reported stolen.Thus, as described in greater detail herein, an EIR associates an IMEIto a registration status or statuses. For example, an EIR may correlatean IMEI (or a range or set of IMEIs) to one of three differentregistration statuses:

-   -   black status, i.e., the device is not allowed to utilize the IMS        core;    -   gray status, i.e., the device is allowed to utilize the IMS        core, but is monitored; or    -   white status, i.e., the device is allowed to utilize the IMS        core.        The EIR 120 may also correlate an IMEI to one or more IMSIs in        order to define valid IMEI/IMSI combinations that are permitted        to use the IMS core 107.

The EIR 120 either comprises or is connected to a capability database(“DB”) 122. As described in greater detail herein, the capabilitydatabase associates an IMEI to one or more device capabilities. Forexample, the capability database may permit the lookup, based on anIMEI, of which location determination techniques are supported by aparticular mobile device's configuration. To illustrate, the capabilitydatabase may permit the EIR to determine whether a mobile device 102having a specific IMEI can be located with Global Positioning Systems(GPS) or assisted GPS (“A-GPS”) methods. Rather than being coupled tothe HSS via the EIR, the capability database may be connected to, oraccessible via, other components within the environment 100. In someexamples, the EIR and/or capability database are configured to acceptand respond to queries for the registration status and/or devicecapabilities of a device from components other than the HSS 114 andS-CSCF 116, either during IMS registration or at other times. Toillustrate, in some examples, the capability database may be queried bya telephone application server, a mobile device 102, and/or athird-party server, such as a server that implements a location-basedservice. The EIR and/or capability database may be queried, for example,via SIP request messages or Diameter messages.

Although not shown in FIG. 1, the IMS core 107 is connected directly orindirectly to location determination components that are configured toinitiate, request or coordinate location determination processes inorder to determine the physical location of a mobile device 102 (e.g.,its latitude and longitude). For example, the IMS core may be connectedto a Gateway Mobile Location Center (“GMLC”), a SUPL Location Center(“SLC”) as described by the SUPL standards available from the OpenMobile Alliance (“OMA”), and/or an Emergency SMLC (“E-SMLC”) asdescribed by the IMS specifications and technical reports of the 3GPP.These components may be configured to determine and provide the locationof a mobile device to a requesting location-based service, such as anemergency service or commercial location-based service. Similarly,although not shown in FIG. 1, the IMS core is directly or indirectlyconnected to location-based applications or services, which utilize thedetermined physical location of a mobile device to providelocation-based services. The IMS core may facilitate communicationsbetween the location-based services, the mobile devices 102, andlocation determination components.

FIG. 2 illustrates an example of an enhanced SIP registration message200 having extended header information. A SIP client running on a mobiledevice 102 generates and sends a registration message to the IMS corenetwork 107 when seeking to register with the network. As shown, theregistration message comprises a request line 205, a header 215, and abody 210. The request line 205 specifies the type of request beingissued (the method token “REGISTER”), a request URI (“telco.com”), and aSIP version (“SIP/2.0”). The header 215 comprises multiple header fieldsthat provide additional information about the request or the SIP client.For example, as shown in FIG. 2, the header may comprise the followingheader fields: Via header 220, To header 225, From header 230, Contactheader 235, CSeq header 240, Call-ID header 245, and Authorizationheader 250. The header may comprise fewer, different, or additionalheader fields than those depicted in FIG. 2. The body 210 carries anydata payload and may be omitted.

A header field may be associated with one or more values. For example,as shown, the To header 225 may be associated with the value“sip:watson@telco.com.” A header field may also be associated withheader field parameters, which may be defined by a value. For example,as shown, the Authorization header 250 may be associated with a “realm”parameter that is defined by the value “telco.com.”

The header 215 is modified in a fashion that facilitates thedetermination of the registration status and the physical location ofthe mobile device. As shown in FIG. 2, the Contact header 235 includesan IMEI 247 that is associated with the mobile device 102 that generatedthe registration message 200. The registration message may indicate theIMEI by associating the IMEI value with an IMEI-specific parameter 249in the Contact header (e.g., as shown, “Contact:+sip.instance=‘123456789101123’”). The Contact header may also includeadditional contact information 257 (e.g.,“<sip:+1-972-555-222@telco.com>”). As another example, although notshown, a registration message may indicate a device's IMEI byconcatenating the IMEI with another value in the Contact header, byassociating the IMEI with another parameter associated with the Contactheader, or by including the IMEI in another header field. In the eventthat the mobile device that generated the registration message is notassociated with an IMEI, the registration message may include astandardized “dummy” IMEI, or otherwise indicate via the registrationmessage that the device does not have an IMEI. For example, if themobile device is not associated with an IMEI, the registration messagemay use a dummy IMEI that comprises the device's IMSI plus a singlecheck digit.

As shown in FIG. 2, the Authorization header 215 includes an IMSI 255that is associated with the mobile device 102 that generated theregistration message 200. The registration message may indicate the IMSIby associating the IMSI value with an IMSI-specific parameter 253 of theAuthorization header (e.g., as shown, “Authorization: Digestimsi_id=‘897654123456789’”). The Authorization header may also includeadditional authorization information 251 (e.g., “username=‘Bob’,realm=‘telco.com’”). As another example, although not shown, aregistration message may indicate a device's IMSI by concatenating theIMSI with another value in the Authorization header, by associating theIMSI with another parameter associated with the Authorization header, orby including the IMSI in another header field. In the event that themobile device is not associated with an IMSI, the message may include a“dummy” IMSI (e.g., a single repeating digit, a number selected from aparticular range, all or part of the device's IMEI), or otherwiseindicate via the message that the device does not have an IMSI.

The flexible syntax of SIP messages allows the IMEI and IMSI to beinserted within the header 215 in a variety of formats. However, sincethe components of the IMS core 107 must be able to reliably andrepeatedly extract IMEI and IMSI information from all registrationmessages, SIP clients running on the various mobile devices 102 areconfigured to observe a predetermined and standardized format forindicating the IMEI/IMSI within a SIP registration message 200.Alternatively, the extended header may include a code or otheridentifier that indicates the selected format of the IMEI and/or IMSIinformation that is contained in the header.

FIG. 3 shows a table 300 schema that conceptually illustrates how acapability database 122 may store location determination capabilities ofmobile devices 102 in association with IMEIs that identify each mobiledevice. As shown in FIG. 3, the table 300 includes a column 305 for anIMEI that uniquely identifies a mobile device 102. Each row 325, 330,335 in the table corresponds to a single IMEI or a set of IMEIs (e.g., arange of IMEIs).

The table 300 also includes one or more location determination columns315, 320, each of which corresponds to a different locationdetermination technique or techniques. For example, as shown in FIG. 3,the table 300 may include an A-GPS column 315 that indicates whether theidentified mobile device 102 is capable of being located using A-GPStechniques. As another example, the table may include a GPS 320 columnthat indicates whether the identified mobile device 102 is capable ofbeing located using GPS techniques. Although FIG. 3 shows only twolocation determination columns 315, 320, the table may have any numberof additional or different location determination columns that reflectwhether a mobile device may be located using a particular locationdetermination technique or techniques. For example, there may be acolumn for any of the following location determination techniques: TimeDifference on Arrival (“TDOA”) (including Uplink-TDOA (U-TDOA), ObservedTDOA (“OTDOA”), Ideal Period Downlink-OTDOA (“IP DL-OTDOA”), and otherTDOA procedures), Cell Identification (“CI”), CI plus Timing Advance(“CI-TA”), Assisted Global Navigation Satellite System (“AGNSS”), RoundTrip Time (“RTT”) measurements, CI plus RTT (“CI-RTT”), EnhancedObserved Time Difference (“E-OTD”), WiFI Data Base location, Customerprovided address location, IP Location, triangulation. Although FIG. 3shows only binary information (“Yes” or “No”), the table mayalternatively or additionally include richer capability information. Forexample, FIG. 3 may include an indication of the performance that may beachieved by using a certain location determination technique to locate aparticular mobile device (e.g., a metric reflecting the accuracy,precision, or time to fix of the technique).

The table 300 also includes one or more software capability columns 340,345. For example, as shown in FIG. 3, the table 300 may include anoperating system specification (“OS specs”) column 340 that indicatesthe operating system installed on the identified mobile device 102. Asanother example, as shown in FIG. 3, the table 300 may include aninstalled applications (“Installed Apps”) column 345 that indicates theapplications installed on the identified mobile device. Installedapplications may include location-based applications (e.g., mappingapplications, local search applications) and/or other types ofapplications. The information contained in the software capabilitycolumns may be utilized by location-based services or other types ofservices or applications.

Although not shown in FIG. 3, the capability database may also indicateother types of capabilities of a mobile device 102 that are related toother applications or services besides location-based services. Thus thetable 300 may have any number of additional or different capabilitycolumns (not shown) that reflect whether a mobile device may utilize aparticular application or service. For example, the table may include anadditional column that reflects whether a mobile device has sufficienthardware/software capability to use a particular multimedia gamingapplication.

Since the capability database 122 may be integrally formed within orotherwise associated with the EIR 120, the table 300 may also include astatus column 310 that indicates the registration status of a mobiledevice. The registration status reflects whether the correspondingdevice is authorized to access the core network, and may take one ormore states (e.g., “black” to indicate that the mobile device is notauthorized to access the network, “white” to indicates that the mobiledevice is authorized to access the network, and “grey” to indicate thatthe device may access the network but have limited use of certainnetwork features or services). For example, as shown in row 335, if amobile device 102 with the IMEI “678910111213131” has been reportedstolen, the table may associate that IMEI with a black status. Asanother example, as shown in row 325, if a group of IMEIs that beginwith the sequence “1234” are known to interoperate with the IMS core107, the table may associate that range of IMEIs with a white status.Although not shown, the table may also include an IMSI column thatdefines valid IMSI/IMEI combinations. These combinations may indicatewhich group of IMSIs (if any) may be utilized in conjunction with aparticular mobile device.

FIG. 4 is a logical flow diagram of a process 400 for utilizing a SIPregistration message 200 having extended header information in order todetermine the registration status of a mobile device 102 and determinethe location of the mobile device. As described in greater detailherein, the various blocks of process 400 may be performed by componentswithin the IMS core 107.

The process 400 begins at block 405, when the IMS core 107 receives aSIP registration message 200 that has extended header information,including IMEI and IMSI information, that was sent from the mobiledevice 102 associated with the IMEI and IMSI. The IMS core 107 receivesthe registration message at the P-CSCF 108, which forwards the messageto the I-CSCF 112.

At block 410, a component of the IMS core 107 parses the extended headerinformation to determine the IMEI and IMSI associated with the mobiledevice 102 that sent the registration message 200. As describedpreviously, the IMS core will be able to extract the IMEI/IMSIinformation so long as the SIP client on the mobile device utilized acorrect predetermined format for the SIP registration message orprovided that the extended header information provides information aboutthe formatting of the SIP registration message. In some examples, theI-CSCF 112 parses the extended header information in the registrationmessage. In other examples, the I-CSCF extracts sufficient informationfrom the message to query the HSS 114 for the identity of the S-CSCF 116that is assigned to handle the registration message. The I-CSCF forwardsthe message to the identified S-CSCF, and the identified S-CSCF parsesthe extended header information in the registration message.

At block 415, the IMS core 107 looks up the device in the EIR 120 usingthe determined IMEI and IMSI in order to determine the status of themobile device 102 and validate the IMSI/IMEI combination.

To determine the status of the mobile device, a component of the IMScore (e.g., the I-CSCF 112 or S-CSCF 116) generates and sends a UARcomprising the IMEI and IMSI to the HSS 114. In some examples, the UARmay reflect the IMSI and IMEI information in a Session ID field and/orUsername field. When the HSS receives the UAR, the HSS queries the EIRusing the received IMEI and IMSI to determine the status of the mobiledevice. In turn, the EIR looks up the IMEI within the EIR database todetermine if the IMEI is associated with a black status, grey status orwhite status. The EIR may also utilize the IMEI and IMSI to verify thatthe two values represent a valid combination. The EIR sends the statusof the mobile device (e.g., black, grey, or white status; valid/invalidcombination of subscriber and mobile device) to the HSS.

Alternatively, rather than send a UAR comprising the IMEI and IMSI tothe HSS 114, the S-CSCF 116 may query the EIR directly in order todetermine the status of the mobile device. In response, the EIR sendsthe status of the mobile device to the S-CSCF.

At decision block 420, the IMS core 107 determines whether to denyregistration to the requesting mobile device 102 due to a determinedstatus. If the IMS core determines that it should deny registration(e.g., due to a black status or invalid combination), at block 425, theIMS core sends a response to the mobile device 102 regarding theregistration failure. The process 400 then returns.

To determine whether to deny registration to the requesting mobiledevice, the HSS 114 reports to the I-CSCF 112 or S-CSCF 116 via a userauthorization answer message (“UAA”) that the mobile device cannotregister with the IMS core. The UAA may specify a failed attribute valuepair. In turn, the I-CSCF or S-CSCF sends a SIP response message to themobile device that indicates a client error status code (e.g., statuscode “403 Forbidden”). The P-CSCF 108 may forward the response messageto the mobile device. Alternatively, the S-CSCF 116 directly interpretsthe response from the EIR to determine whether to deny registration. TheS-CSCF then sends a SIP response message to the mobile device thatindicates a client error status code (e.g., status code “403Forbidden”). The P-CSCF 108 may forward the response message to themobile device.

If the IMS core 107 determines that it should allow registration on thebasis of the received IMEI/IMSI at decision block 420, processingproceeds to block 422. At block 422, the IMS core implements standardIMS authentication and registration processes to continue registeringthe mobile device 102 with the IMS core. If a dummy IMSI was utilized inthe registration message 200 or the registration message indicated thatno IMSI is associated with the mobile device, device authentication mayproceed according to HTTP digest authentication mechanisms. Otherwise,device authentication may proceed according to AKA authenticationmechanisms. To initiate standard processes, the HSS 112 sends a UAA tothe I-CSCF 112 or S-CSCF 116 indicating that the IMSI and IMEI arevalid. Alternatively, the S-CSCF may initiate standard processesdirectly after interpreting the response received from the EIR. Tocomplete IMS core registration, for example, the S-CSCF may send anauthentication challenge to the mobile device with authenticationvectors supplied by the HSS, and if the challenge is satisfied, completethe registration of the mobile device and notify the HSS so that it maybind the IP address of the mobile device.

At block 430, the IMS core 107 looks up the location determinationcapabilities of the requesting mobile device 102 using the determinedIMEI. The HSS or S-CSCF may perform block 430 in conjunction with anyother registration processes, for example, blocks 415, 420, and/or 422.To look up the location determination capabilities, the HSS or S-CSCFmay query the EIR 120 using the received IMEI. The EIR looks up thecapabilities of the mobile device in the capability database 122 usingthe received IMEI, and returns a message to the HSS or S-CSCF indicatingthe location determination capabilities of the mobile device. Forexample, the EIR may return a message to the HSS or S-CSCF indicatingthat the mobile device can be located using GPS and A-GPS techniques. Insome examples, the HSS 112, S-CSCF, or another component directlyqueries the capability DB without interaction by the EIR. In otherexamples, a third-party server or telephone application server queriesthe EIR or capability DB for the location determination capabilities ofthe requesting mobile device using the device's IMEI or anotheridentifier. Such a query may occur at any time, including times otherthan IMS registration.

At block 435, the IMS core 107 stores the location determinationcapabilities of the mobile device 102. For example, the HSS 114 maystore the determined capabilities in association with the IP address ofthe mobile device or a user profile in the HSS. As another example, theHSS or another IMS core component may store the location determinationcapabilities in association with an ongoing session involving the mobiledevice in a session table. For example, the HSS or another component maystore the capabilities in conjunction with session information such as:the IMSI of the mobile device, the IP address of the mobile device,and/or a Media Access Control (“MAC”) address associated with an accesspoint utilized by the mobile device.

At block 440, the IMS core 107 requests and receives the physicallocation of the mobile device 102. The request indicates one or morelocation determination techniques that fall within the capabilities ofthe mobile device that should be utilized to determine the device'sphysical location. To do so, the IMS core may query the HSS 114 oranother system component that stored the location determinationcapabilities of the mobile device. Alternatively, or additionally,another component that is associated with the trusted network 104 and/orthe IMS core (e.g., a GMLC, E-SMLC or SLC) may request that the IMS coreprovide an indication of location determination techniques that fallwithin the capabilities of the mobile device. The other component maythen request or otherwise determine the physical location of the mobiledevice using an indicated location determination technique.

At block 445, the IMS core 107 or another associated component (e.g., aGMLC, E-SMLC or SLC) provides the received physical location of themobile device 102 to a location-based service that has requested themobile device's location. For example, an E-CSCF may provide thereceived physical location to an emergency services network in order toroute an emergency call originating from the mobile device. As anotherexample, the S-CSCF 116 may provide the received physical location to acommercial location-based service such as a mapping service. Therequesting location-based service uses the mobile device's location toprovide services that are tailored to the physical location of thedevice.

Although not shown, at blocks 430-445, the IMS core 107 may also lookup, store and utilize information relating to other capabilities of themobile device 102 using the determined IMEI (or a portion thereof). Forexample, the IMS core may determine whether other types of applicationsor services (e.g., gaming, messaging) are supported by the configurationof the mobile device. The identified capabilities of the mobile devicemay be used to customize services for the particular mobile device.

CONCLUSION

The above Detailed Description of embodiments of the system is notintended to be exhaustive or to limit the system to the precise formdisclosed above. While specific embodiments of, and examples for, thesystem are described above for illustrative purposes, various equivalentmodifications are possible within the scope of the system, as thoseskilled in the relevant art will recognize. For example, while processesor steps are presented in a given order, alternative embodiments mayperform routines having steps, or employ systems having steps, in adifferent order, and some processes or steps may be deleted, moved,added, subdivided, combined, and/or modified to provide alternative orsubcombinations. Each of these processes or steps may be implemented ina variety of different ways. Also, while processes or steps are at timesshown as being performed in series, these processes or steps may insteadbe performed in parallel, or may be performed at different times.

While certain aspects of the invention are presented below in certainclaim forms, the applicant contemplates the various aspects of theinvention in any number of claim forms. Accordingly, the applicantreserves the right to add additional claims after filing the applicationto pursue such additional claim forms for other aspects of theinvention.

We claim:
 1. A non-transitory computer-readable medium containinginstructions that, when executed by a computer processor, register amobile device with an Internet Protocol Multimedia Subsystems (IMS) corenetwork and determine location determination capabilities of the mobiledevice, comprising: receiving a Session Initiation Protocol (SIP)registration message with extended header information from a requestingmobile device, wherein the extended header information includes anindication of an International Mobile Equipment Identity (IMEI) of therequesting mobile device and an International Mobile Subscriber Identity(IMSI) associated with the requesting mobile device; analyzing theextended header information to determine the IMEI and the IMSI of therequesting mobile device; accessing a registration status of therequesting mobile device based at least in part on the IMEI of therequesting mobile device, wherein the registration status is indicativeof whether the requesting mobile device is allowed to utilize the IMScore network; determining whether the combination of the IMEI and IMSIis a valid combination; determining whether to deny registration of therequesting mobile device with respect to the IMS core network based atleast in part on the retrieved registration status of the requestingmobile device and validity of the combination of the IMEI and IMSI; anddetermining location determination capabilities of the requesting mobiledevice using the IMEI of the requesting mobile device in order to allowdetermination of the location of the mobile device.
 2. Thenon-transitory computer-readable medium of claim 1, further comprising:storing the location determination capabilities of the requesting mobiledevice; requesting a physical location of the requesting mobile deviceusing at least one of the stored location determination capabilities;receiving the physical location of the requesting mobile device; andproviding the received physical location of the requesting mobile deviceto a requesting location-based service.
 3. The non-transitorycomputer-readable medium of claim 2, wherein the requestinglocation-based service uses the provided physical location to route anemergency call that originates from the requesting mobile device.
 4. Thenon-transitory computer-readable medium of claim 2, wherein therequesting location-based service is a commercial location-basedservice.
 5. The non-transitory computer-readable medium of claim 1,further comprising retrieving other capabilities of the requestingmobile device using the IMEI of the requesting mobile device.
 6. Thenon-transitory computer-readable medium of claim 1, wherein retrievingthe location determination capabilities of the requesting mobile devicefurther comprises retrieving a performance metric of a locationdetermination technique that may be used to physically locate thedevice.
 7. The non-transitory computer-readable medium of claim 1wherein the IMEI is contained in a contact header field of the SIPregistration message.
 8. The non-transitory computer-readable medium ofclaim 1, wherein the IMSI is contained in an authorization header fieldof the SIP registration message.
 9. The non-transitory computer-readablemedium of claim 1, wherein the extended header information comprises adummy IMEI that comprises the IMSI associated with the requesting mobiledevice and a single check digit.
 10. The non-transitorycomputer-readable medium of claim 1, wherein retrieving locationdetermination capabilities of the requesting mobile device comprisesdetermining whether a physical location of the mobile device can beascertained by a location determination technique selected from thegroup consisting of: TDOA, U-TDOA, OTDOA, IPDL-OTDOA, CI, CI-TA, GPS,A-GPS, RTT, CI-RTT, E-OTD, IP Location, WiFi Data Base location,Customer provided address location, and triangulation.
 11. Thenon-transitory computer-readable medium of claim 1, wherein theretrieved registration status of the requesting mobile device is a blackstatus, a grey status, or a white status.
 12. The non-transitorycomputer-readable medium of claim 1, further comprising sending aresponse to the requesting mobile device if registration of therequesting mobile device with the IMS core network is denied.
 13. Amethod for registering a mobile device with an Internet ProtocolMultimedia Subsystems (IMS) core network, the method comprising:receiving a Session Initiation Protocol (SIP) registration message withextended header information from a requesting mobile device, wherein theextended header information includes: a first unique identifierassociated with the requesting mobile device and an indication of asecond unique identifier associated with a mobile subscriber using therequesting mobile device; determining whether the first uniqueidentifier associated with the requesting mobile device and the secondunique identifier associated with the mobile subscriber using therequesting mobile device is a valid combination; determining whether todeny registration of the requesting mobile device with the IMS corebased at least in part on validity of the combination; retrieving aregistration status using the first unique identifier associated withthe requesting mobile device, wherein the registration status isindicative of whether the requesting mobile device is allowed to utilizethe IMS core; determining whether to allow registration of therequesting mobile device with the IMS core based at least in part on theretrieved registration status of the requesting mobile device; andaccessing location determination capabilities of the requesting mobiledevice using the first unique identifier associated with the requestingmobile device in order to allow the location of the mobile device to bedetermined.
 14. The method of claim 13, wherein the method furthercomprises: storing the location determination capabilities of therequesting mobile device; requesting a physical location of therequesting mobile device using at least one of the stored locationdetermination capabilities; receiving the physical location of therequesting mobile device; and providing the received physical locationof the requesting mobile device to a requesting location-based service.15. The method of claim 14, wherein the requesting location-basedservice uses the provided physical location to route an emergency callthat originates from the requesting mobile device.
 16. The method ofclaim 13, wherein the first unique identifier associated with therequesting mobile device is contained in a contact header field of theSIP registration message.
 17. The method of claim 13, wherein the secondunique identifier associated with the mobile subscriber using requestingmobile device is contained in an authorization header field of the SIPregistration message.
 18. A system for registering a mobile device withan Internet Protocol Multimedia Subsystems (IMS) core network, thesystem comprising: at least one processor; at least one data storagedevice coupled to the at least one processor; means for receiving aSession Initiation Protocol (SIP) registration message with extendedheader information from a requesting mobile device, wherein the extendedheader information includes a first unique identifier associated withthe requesting mobile device and an indication of a second uniqueidentifier associated with a mobile subscriber using the requestingmobile device; means for determining whether the combination of thefirst unique identifier associated with the requesting mobile device andthe second unique identifier associated with the mobile subscriber usingthe requesting mobile device is a valid combination; means forretrieving a registration status using the unique identifier associatedwith the requesting mobile device, wherein the registration status isindicative of whether the requesting mobile device is allowed to utilizethe IMS core; means for determining whether to allow registration of therequesting mobile device with the IMS core based at least in part on theretrieved registration status of the requesting mobile device and onvalidity of the combination of the first unique identifier and thesecond unique identifier; and means for accessing location determinationcapabilities of the requesting mobile device using the unique identifierassociated with the requesting mobile device in order to allow thelocation of the mobile device to be determined.
 19. The system of claim18, further comprising: means for storing the location determinationcapabilities of the requesting mobile device; means for requesting aphysical location of the requesting mobile device using at least one ofthe stored location determination capabilities; means for receiving thephysical location of the requesting mobile device; and means forproviding the received physical location of the requesting mobile deviceto a requesting location-based service.
 20. The system of claim 19,wherein the requesting location-based service uses the provided physicallocation to route an emergency call that originates from the requestingmobile device or wherein the requesting location-based service is acommercial location-based service.